1. Technical Field
This invention relates to the field of speech processing, and more particularly, to testing speech processing applications.
2. Description of the Related Art
Speech processing applications are becoming common for modern interactive services, allowing people to more easily communicate with computers and machines. For example, dialogue management systems facilitate the transfer of information through natural language speaking. Interactive Voice Response systems enable users to connect or route calls to service destinations. Natural language understanding systems allow users to converse with computers for receiving information. As interactive voice services expand to provide more voice enabling features and options, the level of application development grows more complex. Consequently, large scale speech applications can require significant training and testing to provide acceptable performance.
Developers commonly introduce new features to improve or expand the performance of a speech application. The new features can require significant testing before releasing the application to the public. Generally, the developer tests the structural aspects of a speech application as well as the voice recognition and interpretation abilities of the application during development. The testing can include evaluating the entire set of possible outcomes of the speech application. The developer can be burdened with the numerous permutations of testing conditions to evaluate the functionality, quality, or experience of a new feature. The act of testing sections of large speech applications at development time can be time consuming given the level of complexity expected in modern speech applications. Considerable time can be spent testing a new functionality added by a developer, or by a team mate.
In practice, developers build new features on top of existing features for providing new functionality on top of existing functionality. As the speech application grows so too does the call depth to the underlying code sections. New features generally introduce new code on top of existing code which increases the call stack. Accessing the new code can begin at the bottom of the call stack and build up to the new code to satisfy a set of constraints on the existing code. For example, an IVR speech application can resemble a call flow tree with branches that expand outward as new features are added. The branches can represent new avenues for routing, or servicing, a call, thereby introducing more options for the caller to encounter and more options for the developer to test. Reaching a branch can require following a path along any supporting branches while satisfying a set of prior conditions along the path. Also, the branches can interconnect amongst one another leading to an expanded set of possible outcomes, where reaching each branch depends on conditions set by previous branches. Accordingly, each new branch introduces a new set of test conditions along a path which can lead to a more comprehensive testing responsibility.
In general, new code is developed at an increased depth of the call flow tree, or stack, and accessing the new code can require satisfying all conditions along a branch path prior to the new code. For example, to access a new branch, it may be necessary to climb along a path of existing branches satisfying their constraints. Accordingly, reaching a new section of code can require following an entire path to the branch that supports the new code while satisfying all conditions for branches along the path to the new code. A need therefore exists for providing a testing environment to developers which automates testing of new code sections and reduces their test time involvement.